1.1. Field of the Invention
The present invention relates to the field of operation of Information Technology (IT) resources, and the area of automation software. In particular, it relates to a method and respective system for performing a reconfiguration of a plurality of resources, wherein said resources reside on multiple different system platforms including mainframe and distributed systems, with a policy-based automation manager.
1.2. Description and Disadvantages of Prior Art
The present invention can be best applied in enterprises having a relatively large and sophisticated IT-infrastructure, in particular those enterprises which should guarantee a high degree of system availability. A typical example is a bank and the associated IT-environment comprising a mainframe, diverse banking applications running on the mainframe, a plurality of distributed systems running on a UNIX platform and including web servers and respective web applications.
In this disclosure we use the term automation software for software, which automates operator tasks for the purpose of continuous or high application availability.
Within those enterprise computing centers dedicated to support the IT infrastructure, human operators are employed to keep these diverse applications up and running. In order to achieve high levels of availability, software programs—typically called “automation software”—are used to support the operators.
In a functional view prior art automation software often can handle two different scenarios:
Planned scenarios, where an application and the IT resources, e.g., any hardware, software, and processes implemented therein and supporting the application must be stopped, moved, restarted etc. in an effective way for maintenance purposes or for other planned purposes like performing tests etc., or unplanned scenarios, where an application and the respective IT resources fail and must be automatically moved, restarted etc., in an effective way to minimize the impact of the outage.
In a IT-system view the prior art automation software splits up in a script-based and a policy-based approach:
Scripts are often written by a system application programmer or by system administrator staff to implement the desired automation support. A drawback of the script-based approach is that any change in hardware, operating system, middleware or application setup results in very labor-intensive updates and tests of the automation scripts.
Software vendors sell automation products, which typically have to be customized before they can be used to automate IT resources. These vendor automation products are also often script based. This means, that the system administrator staff must write script plug-ins to implement the desired automation support. Here, the drawbacks are identical to that ones described above.
Other vendor automation software is policy-based. In this context an “automation policy” is an abstract configuration description of the application and the IT resources needed to run the application. A prior art automation policy typically consists of “grouping concepts” and of relationships. In comparison to the script-based approach the policy-based approach has benefits. It is easy to adapt to changes in hardware, operating system, middleware or application setup, because only a few changes in the automation policy definition are needed to reflect a new configuration.
With particular respect to the present invention most automation vendor products (script-based or policy-based) do not support cross-cluster or cross-platform automation. When automating unplanned scenarios, automation software typically runs in a homogeneous, clustered environment only, or on a single node only. If external resources need to be automated, often a simple script mechanism with remote execution is used to provide rudimentary cross-cluster or cross-platform support. This however, is not sufficient to support a transit from one configuration to another, for example for test purposes, as the remote platform or remote cluster is too complex for being able to be re-configured by a simple and short piece of script.
Policy-based automation products support exemplarily the following group concepts:
Basic group: a group of resources—see resources 11 in FIG. 1, which is available if and only if all members of the group are available.
Server group: a group of resources 11, which is available if and only if the number of available members is larger than a given threshold number.
Move group: a group of resources 11, which is available if and only if exactly one of the members is available; when a system hosting one of the members fails, another member of the group hosted on a different system is started automatically.
It should be noted that different automation products use different names for the above groups, while they still keep the above described semantics.
With reference to FIG. 1 a schematic prior art system view is given. An enterprise may be assumed to have an IT-infrastructure comprising a mainframe cluster (e.g. a IBM-zSeries sysplex) 10 and two further UNIX clusters 12 and 14. Mainframe automation as described above is based on an automation policy stored in a policy store 16. The automation of the UNIX clusters 12, 14 is based on automation scripts stored in respective script stores 18, 20.
Enterprise-level reconfigurations including diverse platforms—e.g. mainframe 10, UNIX 12, 14, maybe WINDOWS—are mostly planned operations. They are typically performed by human operators depicted in the upper part of FIG. 1. Often multiple operators work together, if their skill is platform-specific and different platforms are involved.
This is depicted in FIG. 1. In sophisticated IT enterprises, the human operator can not foresee what a consistent configuration is and which other configurations can be selected alternatively and under which conditions they can be selected. Thus, enterprise-level reconfigurations of resources 11 takes much time as all configuration work must be agreed—often accompanied by long telephone calls—on between the respective system administrators before it is performed.
This is highly relevant for mission-critical applications like banking environments. About 70% of important data such as financial transfer data in banking application reside still on mainframes, although with the increasing relevance of Web-based services, enterprises increasingly have implemented UNIX-based servers and WINDOWS-based systems. But as a mainframe platform offers a proven, trusted, and quite stable long-time performance in particular with huge amounts of data, they represent the backbone in a banking IT infrastructure. Thus, heterogenous IT infrastructures, comprising the main frames and UNIX based systems coexist and are subjected to above-described reconfiguration scenarios. Disadvantageously, prior art automation software, however, is not able to offer a consistent, error-free support for configuration changes across the different platforms, or across different clusters.
1.3. Objectives of the Invention
It is thus an objective of the present invention to provide a reconfiguration method with an improved switching facility between such configurations.